VMware Cloud on AWS data transfer charges: How it works? – VMware Cloud Community

I am often asked a lot of questions about data transfer charges and more specifically data egress charges from VMware Cloud on AWS. This, in my opinion, is a very valid consideration and data transfer should be taken into account, for various reasons from both technical architecture and cost perspective.

However, my observation shows that when it comes to egress cost, there is still a concern and possibly a misconception that data transfer charges are extremely high, unpredictable or uncontrollable and because of that the Cloud results in somewhat of a “Hotel California” proposition – you can check in, but you can never leave.

This, of course, is not the case.

As with most things, the honest answer of “How much is it going to cost?” is – it depends! But the good news is that we have the expertise and fantastic tools at our disposal to very easily estimate, control and budget for these costs as environments grow, change and evolve over time.

Because every customer’s environment and workload are different, I thought it will be useful to first of all understand how and when egress costs apply and then provide a framework of estimating those.

How to approach estimate egress cost calculations?

There are two main variables in data egress calculations. The first one is the amount of data; and the second is the point of egress. So, let’s have a look at how these apply.

To do so, we need to understand the VMware Cloud on AWS account structure and how that relates to data charges in a bit more detail.  I would refer to my colleague Gilles Chekroun’s blog post, which provides a fantastic explanation and breakdown of different data charges within VMware Cloud on AWS and AWS’ Cloud space.

Understanding Point of Egress

The below diagram shows the different charges and egress points, depending on whether data is being transferred within or outside of an AWS region.

Source: Understanding VMware Cloud on AWS Account Structure and Data Charges

One of the most common use cases for VMware Cloud on AWS is workload migration.  That could be anything from a sub-set of workloads, which are better placed in the Cloud to an entire datacenter migration.

In this case, customers typically require connectivity to their on-premises environment via either a Direct Connect (DX) or VPN connection over the Internet. And this would be where most of the data flow is.

Based on the connectivity choice, as shown above, different charges apply – $0.02/GB and $0.05/GB over DX and VPN respectively, for regions locates in the US and EMEA. Note, that costs can vary, and it is always advisable to check these for the region and, if applicable, DX provider you are planning to use.

In some cases, customers decide to deploy VMware Cloud on AWS in what we call a Stretched Cluster. In simplest terms, a Stretched Cluster SDDC is a VMware Cloud on AWS SDDC, which is deployed across two AWS Availability Zones (AZs), increasing data and service availability, by effectively providing enough resources to survive an entire AZ going offline. That requires vSAN to make sure that data is protected (mirrored) across both AZs.

There is a cost associated with data transfer, between AWS AZs, but the great thing about VMware Cloud on AWS is that we offer a 95% discount on the Cross AZ network fees resulting from Stretched Cluster operations. So, the cost is truly tiny.

But it gets even better. Effective immediately, ten petabytes per month of Cross-AZ charges are included with any Stretched Cluster deployed within the service. Therefore, the cost is practically 0.

And finally, when customers adopt VMware Cloud on AWS, they almost immediately start leveraging AWS native services alongside the workloads running in their SDDC. Initially for backup purposes, closely followed by AWS native file services. Those would typically be configured, so that they use the VMware Cloud on AWS Elastic Network Interface (ENI) connection for data flow. And of course, that is free!

Understanding Data

 When it comes to data, again there are a couple of things to consider.

The first one is the workload capacity. That is very straight forward. It is the amount of data, managed by the VMs themselves. It is typically well known and there are multiple ways to confirm. A variety of industry standard tools exist, to get a more detailed understanding of workload profiles.

The second piece is data resulting from other operations, such as data transfer resulting from communication between users or machines within and outside of VMware Cloud on AWS, data change rate and so on.

This part is a little trickier to estimate because it is very dynamic, but this is where our vRealize portfolio proves invaluable. It allows customers to gain very granular visibility of network flows, analyse trends, find VM optimization suggestions and much more.

Summary

 In summary, egress costs are variable costs, which depend on workload demand. When we understand the workload profile and basic structure of the new cloud environment, we can very easily estimate and control those cost, by leveraging different tools and workload placement options to design a truly flexible environment, underpinned by a modern cloud infrastructure.

To put this to the test and for more detail about how to calculate egress costs, you can use the VMware Cloud on AWS Egress Estimate Guide available here.

Resources

For other information related to VMware Cloud on AWS, here are some more learning resources for you: